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Abstract 

Shape types are a general concept of process types which work for 
many process calcuh. We extend the previously published Poly>(^ system 
of shape types to support name restriction. We evaluate the expressiveness 
of the extended system by showing that shape types are more expressive 
than an implicitly typed 7r-calculus and an explicitly typed Mobile Ambi- 
ents. We demonstrate that the extended system makes it easier to enjoy 
advantages of shape types which include polymorphism, principal typings, 
and a type inference implementation. 

1 Introduction 

Many type systems for many process calculi have been developed to statically 
guarantee various important properties of processes. Types differ among these 
systems and their properties, such as soundness, have to be proved separately 
for each system. Shape types are a general concept of polymorphic process types 
which can express and verify various properties of processes. Poly* [T^llII] is a 
general framework which, for a wide range of process calculi, can be instantiated 
to make ready-to-use sound type systems which use shape types. Only rewrit- 
ing rules satisfying common syntactic conditions are needed for instantiating 
Poly*. 

Many process calcuh share semantically equivalent constructions, such as, 
parallel composition ( " I " ) , prefixing a process with an action (sometimes called a 
capability) ("■")! ^'Hd name restriction ("j^")- Specific calculi differ mainly in the 
syntax and semantics of actions (capabilities). Meta* [121 E] is metacalculus 
which fixes semantics of the shared constructions and provides a way to describe 
syntax and semantics of actions by a description TZ of rewriting rules. Given 
TZ, Meta* makes the calculus C-ji and Poly* makes the type system S-ji 
for C-jz- can describe many calculi including, e.g., the 7r-calculus, Mobile 
Ambients, numerous variations of these, and other systems. All instantiations of 
Poly* share shape predicates which describe allowed syntactic configurations of 
Meta* processes. Shape (TZ-)types of Stz are shape predicates whose meaning 
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is guaranteed by a simple test to be closed under rewriting with TZ. Every Sn 
has desirable properties such as subject reduction, the existence of principal 
typings [T7j, and an already implemented type inference algorithrr0. 

1.1 Contributions 

This paper extends the PoLY* system to support name restriction and also 
proves POLY^ shape types are more expressive than some previous systems 
for specific calculi. The contributions are as follows. (1) Sec. [5] presents the 
extended Poly* system. Sections [3l |4] show (2) how to easily use shape 
types with well-known calculi (the 7r-calculus [Ml [13], Mobile Ambients [3]), 
(3) demonstrate polymorphic abilities of shape types, and (4) prove that shape 
types are more expressive than predicates of two type systems {implicitly typed 
TT-calculus |16| . explicitly typed Mobile Ambients [4J custom designed for the 
above calculi. Finally, (5) we advocate a generic notion of shape types and show 
that they can be used instead of predicates of many other systems. We consider 
contributions (4) & (5) to be the main contribution of the paper. 

Contribution (2) shows how to use Poly* and shape types without needing 
to fully understand all the details of the underlying formalism. Thus it helps to 
bridge over the problem of complexity of Poly* which is inevitably implied by 
its high generality and which has been daunting to some readers of earlier papers. 
Contribution (3) shows an aspect of shape types which is not common for other 
systems. An accompanying technical report [9j (TR), which extends this paper 
and contains proofs of main theorems, additionally shows how to use shape types 
for flow analysis of BioAmbients and proves its superior expressiveness to an 
earlier flow analysis system .15 . This work was left out for space reasons. For all 
the three systems we have proven not only that shape types are more expressive 
but also that they can be used to achieve exactly the same results as the original 
systems which might be important for some of their applications. We believe 
that the diversity of the mentioned systems and their intended applications 
provides a reasonable justification for contribution (5). 

1.2 Notations and Preliminaries 

Let i, j, k range over natural numbers. VnniU) is the set of all finite subsets of 
a set U, "\" denotes set subtraction. Let u (— )■ w be an alternate pair notation 
used in functions, /[w-^v] stands for the function that maps u to f and other 
values as /. Moreover, U ^ V {U -^^^ V) is the set of all (all finite) functions 
/ with dom(/) C U and rng(/) C V. 

^http: //www. macs .hw. ac .uk/ultra/polystar (includes a web demonstration) 
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Figure 1: Syntax of Meta* processes. 
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Figure 2: Meta* structural equivalence (structural rules omitted). 



2 Metacalculus Meta^^c and Generic Type Sys- 
tem POLY^jf 

2.1 General Syntax of Processes 

Meta* process syntax, presented in Fig. [TJ allows embeddings of many 
calculi. A name a* is a pair of a basic name a and a natural number i. The 
basic part of a name x is denoted x, that is, = a. When a-converting, we 
preserve the basic name and change the number. We write a instead of a*' when 
no confusion can arise. 

Processes are built from the null process "0" by prefixing with an action 
("."), by parallel composition ("I"), by name restriction ('V'), and by replica- 
tion ("!"). Actions can encode prefixes from various calculi such as 7r-calculus 
communication actions, Mobile Ambients capabilities, or ambient boundaries. 
The abbreviation "xi . . . Xk [PI " , which further supports ambient syntax, stands 
for "xi . . .Xkll -P" ( [] is a single name). 

Process constructors have standard semantics. "0" is an inactive process, 
"A.P" executes the action A and continues as P, "P I Q" runs P and Q in 
parallel, "I'x.P" behaves as P with private name x (i.e., x differs from all names 
outside P), and acts as infinitely many copies of P in parallel ("P I P I ■ • ■ "). 
Let "." and 'V" bind more tightly than " I " . These constructors have standard 
properties given by structural equivalence = (Fig. [2]), e.g., "1" is commutative, 
adjacent 'V can be interchanged, etc. In contrast, the semantics of actions 
is defined by instantiating Meta* (see below). Currently, Meta* does not 
support the choice operator "+" as a built in primitive. However, "P + Q" can 
be encoded as "ch.(P I Q)" provided rewriting rules are extended to use this 
encoding. 

All occurrences x in 'Vx.P" are (i/-)bound. When the action A contains an 
element "(xi, . . . ,Xk)" then all occurrences of the Xi's in "A.P" as well as in 
A on its own are called (input-)bound. An occurrence of x that is not bound 
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is free. The occurrence of a in a* is bound (resp. free) when this occurrence 
of a* is. A bound occurrence of a' can be a-converted only to with a the 
same. We identify a-convertible processes. The set of free names of P is denoted 
fn(P). The set fbn(P) (resp. ibn(P), nbn(P)) contains free (resp. input-bound, 
i^-bound) basic names of P. The set of bound names of A is written bn{A). 

A process P is well scoped when (Wl) fbn(P), ibn(P), and nbn(P) do not 
overlap, (W2) nested input binders do not bind the same basic name, and (W3) 
no action contains an input-binding of a basic name more than once. These 
conditions are important for type inference. We allow only well scoped processes. 

A Meta* substitution ct is a finite function from Name to Message. Applica- 
tion of a to P, written Per, behaves as usual except the following. (1) It places 
a special name "•" at positions that would otherwise be syntax errors (e.g., 
(in x.O){x M> out b} — in •.0). (2) When a composed message M is substituted 
for a single name action x in "x.P" , then Af 's components are pushed from right 
to left onto Pa (e.g., (x.O){x ^ (a.b).c} — a.b.c.O). The full definition of Pa is 
in the TR. 

2.2 Instantiations of Meta* 

META>(f provides syntax to describe rewriting rules that give meaning to actions 
and also defines how these rules yield a rewriting relation on processes. The 
syntax is best explained by an example. The following rule description (in 
which "{x : = njQ" describes substitution application) 

revifrite{ c<n>.P I c(x).Q^P I {x : = n}q> 

directly corresponds to the standard 7r-calculus communication rule "c<n>.P I 
c{x).Q => P I Q{x n}". The circle-topped letters stand at the place of 
name, message, and process metavariables. Given a set TZ of rule descriptions 
in the above syntax, Meta* automatically infers the rewriting relation ^ 
which incorporates structural equivalence and congruence rules (e.g., "P^Q =^ 
vx.P'-^vx.Q^^). A rules description instantiates Meta* to a particular calculus, 
e.g., the set TZ containing only the above rule description instantiates Meta* 
to the TT-calculus. 

Further examples of Meta* instantiations are given in Sec. 13.31 and 14.31 A 
rule description can also contain a concrete Meta* name (e.g. "out") when 
an exact match is required. We require that these names are never bound in 
any process. Complete definitions of the syntax of rewriting rules and of the 

rewriting relation > is left to the TR [9l Sec. 2.2]. 

2.3 Poly*: Shape Predicates and Types for Meta^Ic 

A shape predicate describes possible structures of process syntax trees. When 
a rewriting rule from TZ is applied to a process, its syntax tree changes, and 
sometimes the new syntax tree no longer satisfies the same shape predicates. 
All Poly* (7?.-)types are shape predicates that describe process sets closed 
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Syntax of Poly* shape 
ip € FormType ::= 
<1> € FormTypeSet 
H G MessageType 
£ G ElementType 



.icates: 
:= ao . . . afc 
= Pfin (FormType) 
:= $* I a 
:= a I (ai, . . . , a^) 
<^ii, . . . , ^ifc> 



a £ ActionType 

X € Node 

77 G Edge 

G G ShapeGraph 

TT G ShapePredicate 



= eo El ■ 
= X I Y 1 



= Xo -> Xi 
= 7%n(Edge) 

= (G,x> 



Rules for matching Meta* entities against shape predicates: 

ha' -.a h{a!:,\...,a^) : {ai,...,ak) (hA/o : $ & l-A/i : hMo.Afi : <E> 

hO:$ (hF:<^&<^G'l')^l-F:$ (A/ ^ Name & h A/ : $) ^ hA/ : $* 



(Vi < fc: : Ei) h^o ...Ek-eo-.-Ek 

{\fi: < i < k : m) ^ \-<Mi,.. .,Mk> : <fJ,i, 



■ ,Mfe> 



ho : TT 

hP-.TV^hlP-.TT 



(hP:7r&|-Q:7r)^|-P I Q : tt 

((xo ^Xi) eG&hA:a&hP: (G,xi))^^v4.P: {G,xo> 



Figure 3: Syntax and semantics of Poly* shape predicates. 



under rewriting using TZ. For feasibility, types are defined via a syntactic test 
that enforces rewriting-closedness. Intuitively, the syntactic test tries to apply 
the rules from TZ to all active positions in a shape graph and checks whether all 
the edges newly generated by this application are already present in the graph. 
Further restrictions are used to ensure the existence of principal typings. 

Fig. [3] defines shape predicate syntax. Action types are similar to actions 
except that action types are built from basic names instead of names, and 
compound messages are described up to commutativity, associativity, and rep- 
etitions of their parts. Thus an action type describes a set of actions. A shape 
predicate (G, x) is a directed finite graph with root x and with edges labeled by 
action types. A process P matches tt when P's syntax tree is a "subgraph" of 
TT. Shape predicate can have loops and thus describe syntax trees of arbitrary 
height. 

Fig. [3] also describes matching Meta* entities against shape predicates. 
The rule matching actions against action types also matches forms against form 
types. Matching entities against types does not depend on TZ, i.e., it works the 
same in any Meta* instantiation. The meaning |7r| of the shape predicate tt 
is the set {P\ hP : tt} of all processes matching tt. 

A shape predicate tt is semantically closed w.r.t. a rule set TZ when [tt] is 

TZ 

closed under 7?,-rewritings, i.e., when \- P : tt and P ^ Q imply \-Q -.tt for any 
P and Q. Because deciding semantic closure w.r.t. an arbitrary TZ is nontrivial, 
we use an easier-to-decide property, namely syntactic closure, which by design 
is algorithmically verifiable. TZ-types are shape predicates syntactically closed 
w.r.t. TZ. A type tt of P is a principal typing of P when |7r| C [tto] for any 
other type ttq of P. There are width and depth restrictions to ensure principal 
typings. Details are left to our TR [9, Sec. 2.4]. 
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2.4 Proving Greater Expressiveness of Poly* 

We now discuss how to consider some process calculus C and its type system Sc 
and prove the greater expressiveness of the related Meta* and Poly* instan- 
tiations. Sections [3] and H] follow this approach. Usually Sc defines predicates 
(ranged over by ip) which represent properties of processes (ranged over by B) 
of C . Then Sc defines the relation \> B -.tp which represents statements "i? has 
the property and which is preserved under rewriting of B in C . The Meta*: 
description TZ of C"s rewriting rules gives us the calculus C-r and its shape type 
system Su- 

Firstly we need to set up a correspondence between C and C-ji, that is, we 
need an encoding (•]) of processes B into Meta* which preserves C"s rewriting 
relation The following property, which is usually easy to prove, formulates 
this modulo = because structural equivalences of different calculi might differ. 

Property 2.1 When Bq^Bi then 3B'q,B[ such that Bq = B'^ k {B'^) A 
{B[) kB[=Bi. When {Bq} A Pi then 3Bi such that Bq^BiSz {Bi} = Pi. 

Predicates ip of Sc are commonly preserved under renaming of bound basic 
names, that is, \>{yx)B : tp usually implies [>{va^){B{x i-^ a^}):p (for a not 
in B). Predicates of similar systems can not be directly translated to Poly* 
shape types with the corresponding meaning because shape types do not have 
this property. In other words, the difference in handling of bound names between 
POLY'I^ and other systems makes some straightforward embeddings impossible. 

We investigate two reasonable ways to embed Sc in 5*7^, that is, to decide 
\>B:p using S'tj's relation "h". (1) In Sec. 14.41 about Mobile Ambients, we 
translate p> together with information about bound basic names of B into a 
shape type. (2) In Sec. 13.41 about the 7r-calculus, we show how to decide l> B -.ip 
by a simple check on a principal shape type of B. The fact that both embeddings 
of predicates p depend on a process B is not a limitation because B is known 
for desirable applications like type checking. 

We stress that these embeddings serve the theoretical purpose of proving 
greater expressiveness and are not necessary for a practical use of shape types. 
When Sc is designed to verify a certain fixed property of processes which can 
be expressed as a property of shape types, then we can use Sn directly for the 
same purposes as Sc without any embedding. We show how to do this for the 
two systems in Sec. 13.31 and 14.31 We can also design a property of processes 
directly on shape types without any reference to another analysis system. Our 
TR O Sec. 3] discusses this further. 

2.5 Discussion 

Poly* presented above extends the previously published Poly* [12] with name 
restriction. The previously published system |12j supports restriction only in 
Meta* but no processes with v are typable in Poly* instantiations. An earlier 
attempt in a technical report [llj to handle name restriction was found incon- 
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Syntax of the iv-calculus processes: 

c,n,m £ PiName = Name \ {•} 

A'^ £ PiAction ::= c(ni, . . . , Uk) \ c<ni, . . . , nk> 
B e PiProcess | (Bo I Bi) | N.B \ \B j {un)B 

Rewriting relation of the n-calculus (= is standard defined in TR Fig. 8]): 
c(ni, . . . , rife). Bo I c<mi, . . . , mk>.Bi -5> Bo{ni n> mi, . . . , nfc n> rrik} I -Bi 

Bo -> Bi ^ im)Bo {vn)Bi B'o = Bo k. Bq Bi k Bi = B[ => B'q B[ 
Bo ^ Bi Bo I B2 Bi I Ba 

Figure 4: The syntax and semantics of the 7r-calculus. 



sistent [SI Sec. 3.2-4] and furthermore inadequate P| Sec. 4] to carry out the 
proofs of greater expressiveness in sections [3] and H] 

The difficulty with name restriction is because a shape type represents a 
syntactic structure of a process, and thus presence of bound names in a process 
has to be somehow reflected by a shape graph. Because bound names can be a- 
renamed, Poly* needs to estabhsh a connection between positions in a process 
and a shape graph which is preserved by a-conversion. This connection is 
provided by basic names which are the key concept of name restriction handhng 
in this paper. For example, for the action "a<a>" there is the corresponding 
action type "a<a>" in its shape type. When the name a were v-honnA and a- 
renamed to some other name then the correspondence between the action in the 
process and the action type would be lost. This problem is solved by building 
shape types from basic names which are preserved under a-conversion. 

The handling of input-bound names in the previous Poly>(^ was reached by 
disabling their a-conversion which is possible under certain circumstances. But 
a-conversion of i/-bound names can not be avoided and thus a new approach 
has been developed. 



3 Shape Types for the 7r-calculus 
3.1 A Polyadic vr-calculus 

The TT-calculus [HI [13] is a process calculus involving process mobility developed 
by Milner, Farrow, and Walker. Mobility is abstracted as channel-based commu- 
nication whose objects are atomic names. Channel labels are not distinguished 
from names and can be passed by communication. This ability, referred as link 
passing ^ is the 7r-calculus feature that most distinguishes it from its predecessors. 
We use a polyadic version of the 7r-calculus which supports communication of 
tuples of names. 

Fig. [5] presents the syntax and semantics of the 7r-calculus. Processes are 
built from Meta* names. The process "c(ni, . . . ,rife).i?", which (input)-binds 
the names n^'s, waits to receive a fc-tuple of names over channel c and then 
behaves like B with the received values substituted for m's. The process 
"c<ni, . . . , nfe>.i3" sends the A:-tuple ui, . . ., over channel c and then be- 
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Syntax of TPI types: 




P e 


PiTypeVariable ::= i | i' i" | ■ ■ • 


5 e 


PiType ■■= p\t[Si,...,Sk] 


A G 


PiContext = BasicName — 5-fi„ PiType 


Typing rules of TPI; 




A h 


A h Bo & A h Bi ^ A h Bo 1 Bi 


AhB^AMB A[riH^(5]hB^Ah (z/ri)^ 


A(c) = t[5i,...,4 


& A[ni . . . ,rzfc 4] h B =^ Ah c(ni, . . .,nk).B 


A(c) = t[A(ni),.. 


, A(nfc)] & A h B ^ A h c<ni, . . .,nk>.B 



Figure 5: Syntax of Tpi types and typing rules. 



haves like B. Other constructors have the meaning as in Meta* (Sec. 12. ip . 
The sets of names fr\{B), fbn(B), ibn(B), nbn(_B) are defined as in Meta*. 

Processes are identified up to a-conversion of bound names which preserves 
basic names. A substitution in the 7r-calculus is a finite function from names 
to names, and its application to B is written postfix, e.g., "_B{n ^ m}". A 
process B is well scoped when (SI) fbn(i3), ibn(i3), and nbn(i3) do not overlap, 
(S2) nested input binders do not bind the same basic name, and (S3) no input 
action contains the same basic name more then once. Henceforth, we require 
processes to be well scoped (well-scopedness is preserved by rewriting). 

Example 3.1 Lef B = !s(x, y) .x<y>.0 I s<a, n>.0 |a(v).v(p).0 I n<o>.0 I 

|s<b,m>.0 I b(w).v(q, r).0 I m<o,o>.0 

Using the rewriting relation — >■ sequentially four times we can obtain (among 
others) the process is(x, y) .x<y>.0 I n(p).0 I n<o>.0 I m(q,r).0 I m<o,o>.0". 

3.2 Types for the Polyadic vr-calculus (TPl) 

We compare Poly* with a simple type system [121 Ch. 3] for the polyadic 
TT-calculus presented by Turner which we name Tpi. Tpi is essentially Milner's 
sort discipline jl3j . In the polyadic settings, an arity mismatch error on channel 
c can occur when the lengths of the sent and received tuple do not agree, like in 
"cCn) .0 I c<m, TO>.0" . Processes which can never evolve to a state with a similar 
situation are called communication safe. Tpi verifies communication safety of 
TT-processes. 

The syntax and typing rules of Tpi are presented in Fig. [3 Recall that n 
denotes the basic name of n. Types S are assigned to names. Type variables (3 
are types of names which are not used as channel labels. The type "t[<5i, ■ ■ ■ ,Sk\" 
describes a channel which can be used to communicate any fc-tuple whose i-th 
name has type Si. A context A assigns types to free names of a process (via 
their basic names). The relation A h i?, which is preserved under rewriting, 
expresses that the actual usage of channels in B agrees with A. When A h B 
for some A then B is communication safe. The opposite does not necessarily 
hold. 
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Example 3.2 Given B from Ex. \3.1\ we can see that there is no A such that 
A h _B. It is because the parts s<a,n> and s<a,m> imply that types of n and 
m must be equal while the parts n<o> and m<o,o> force them to be different. 
On the other hand B is communication safe. We check this using POLY* in 
5ec[M 



3.3 Instantiation of Meta* to the vr-calculus 



The TT-calculus syntax from Sec. 13.11 already matches the Meta* syntax and 
thus only the following V is needed to instantiate Meta* to the calculus C-p 
and Poly* to its type system S-p. Sec. l3.4l shows that C-p is essentially identical 
to the above 7r-calculus. 

V = Ur=o {rewrite{ c<Mi, . . . ,Mfc>.P I c(ai, . ..,kk).Q P Kai : = Mi, . . . , : = Mfe>q }} 

Each communication prefix length has its own rule; in our implementation, a 
single rule can uniformly handle all lengths, but the formal Meta* presentation 
is deliberately simpler. The next example shows how to check communication 
safety in Sp without using Tpi. 

Example 3.3. Let P be a Meta* equiva- 
lent of B from Ex. 13.11 We can compute a 
principal P-type 7rp of P which is displayed 
on the right. Node R is its root. The type 
TTp contains all computational futures of P 
in one place. Thus, because there are no two 
edges from R labeled by "a(6i, . . . , and 
"a<b[, . . . , 6^>" with k j, we can conclude 
that P is communication safe which Ex. 13.21 
shows Tpi can not do. Our implementation can be instructed (using an addi- 
tional rule) to insert the error name • at the place of communication errors. 
Any type of P without • then implies P's communication safety. 




3.4 Embedding of TPI in POLY^jc 

Using the terminology from Sec. 12.41 we have that C is the 7r-calculus, Sc is 
Tpi, predicates (p of Sc are contexts A, and S'c's relation [> B : ip is A \- B. 
Moreover TZisV which was introduced with Cp and Sp in Sec. 13.31 This section 
provides a formal comparison which shows how to, for a given B and A, answer 
the question A h P using Sp. 

As stated in Sec. 12.41 to relate Tpi and S-p we need to provide an encoding 
(•) of vr-processes in Meta*. This (•), found in TR [9, Fig. 10] , is almost an 
identity because the 7r-calculus syntax (Fig. S]) already agrees with Meta*. 
Thus {■} mainly changes the syntactic category. Prop. 12.11 holds in the above 
context. 

Given A, we define a shape type property which holds for the principal type 
ttb of {B} iff A h P. The property is given by the relation A = tt from Fig. |6l 
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The set of expected and actual channel types of G: 

chtypes(A,G) = {(A(a), t[A(6i), . . . , A(6,)]): (x ''"'"-•'"°'> x') £ GV(x x') £ G; 

Context A anrf shape type tt agreement relation 

Write A = (G, x) when there is some A' with the domain disjoint from A such that 
chtypes(A U A', G) is defined and is an identity. 

Figure 6: Property of shape types corresponding to h of Tpi. 

The set chtypes(A, G) contains pairs of TPI types extracted from G. Each 
pair corresponds to an edge of G labeled by an action type "a(&i, . . . , or 
"a<6i, . . . , 6fc>". The first member of the pair is a's type expected by A, and 
the second member computes a's actual usage from the types of 6i's. The set 
chtypes(A, G) is undefined when some required value of A is not defined. The 
context A' from the definition of = provides types of names originally bound in 
B. These are not mentioned by A but are in G. The following theorem shows 
how to answer A h S by =. 

Theorem 3.1 Let no two different binders in B bind the same basic name, ttb 
be a principal (V-)type of {B} , and dom(A) = fbn(i?). Then A \- B iff A = ttb ■ 

The requirement on different binders (which can be achieved by renaming) 
is not preserved under rewriting because replication can introduce two same- 
named binders. However, when all binding basic names differ in Bq, then the 
theorem holds for any successor Bi of Bq even when the requirement is not 
met for Bi. We want to ensure that the derivation of A h i? does not assign 
different types to different bound names. A slightly stronger assumption of 
Thm. 13.11 simplifies its formulation. The theorem uses principal types and does 
not necessarily hold for a non-principal V-type tt of {B} because tt's additional 
edges not needed to match {B] can preclude A ^ tt. 

3.5 Conclusions 

We showed a process (Ex. 13. ip that can not be proved communication safe by 
Tpi (Ex. [3?2]) but can be proved so by Poly* (Ex. [331). Thm. [XT] implies 
that Poly* recognizes safety of all Tpi-safe processes. Thus we conclude that 
Poly* is better in recognition of communication safety then Tpl Thm. 13.11 
allows to recognize typability in Tpi: B is typable in TPI iff = ttb- This is 
computable because a Poly* principal type can always be found (for S-p in 
polynomial time), and checking = is easy. 

Turner TF, Ch. 5] presents also a polymorphic system for the 7r-calculus 
which recognizes B from Ex. 13.11 as safe. However, with respect to our best 
knowledge, it can not recognize safety of the process "B I s<n,a>.0" which 
Poly* can do. We are not aware of any process that can be recognized safe by 
Turner's polymorphic system but not by Poly*. It must be noted, there are 
still processes which Poly* can not prove safe, for example, "a (x) .a (y, z) .0 I 
a<o>.a<o,o>.0". 
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Syntax of Ma processes: 



n £ AName 

iV e ACapability 

(jj G AMessageType 

B e AProcess 



Name \ {•} 

e I n I in iV I out iV I open iV | iV.iV' 
definition postponed to Fig. [8] 
I (Bo I Bi) I NlBl I N.B \ IB \ {un:uj)B \ 
<Ni,...,Nk> I (ni:cji,...,nfe:a;fc).B 



Rewriting relation of Ma (= is standard defined m TR |3 Fig. 12]): 
n[in m.Bo I Bi] I mCBa] ^ mlnWo I Bil I B2] 
m[n [out m.Bo I Bi] I B2I n[Bo \ Bi] I m[B2] 
open n.Bo I n[_Bi] Bq \ Bi 
(ni:uji,...,nk:ujk).B \ <Ni,...,Nk> B{ni Ni, . . . ,nk Nk} 

Bo ^ Bi => nLBol — !> nCBi] Bo ^ Bi ^ {un:ijj)Bo -> {un:ijj)Bi 

Bo-^ Bi ^ Bo \ B2 ^ Bi \ B2 B'o = Bo &c Bo ^ Bi L Bi = B[ ^ B,', -> Bj 



Other TT-calculus type systems are found in the Uterature. Kobayashi and 
Igarashi [7] present types for the 7r-calculus looking like simplified processes 
which can verify properties which are hard to express using shape types (race 
conditions, deadlock detection) but do not support polymorphism. One can 
expect applications where Poly* is more expressive as well as contrariwise. 
Shape types, however, work for many process calculi, not just the 7r-calculus. 

4 Shape Types for Mobile Ambients 
4.1 Mobile Ambients (Ma) 

Mobile Ambients (Ma), introduced by Cardelli and Gordon [3^, is a process 
calculus for representing process mobility. Processes are placed inside named 
bounded locations called ambients which form a tree hierarchy. Processes can 
change the hierarchy and send messages to nearby processes. Messages contain 
either ambient names or hierarchy change instructions. 

Fig. [7] describes Ma process syntax. Executing a capability consumes it and 
instructs the surrounding ambient to change the hierarchy. The capability "in n" 
causes moving into a sibling ambient named n, the capability "out n" causes 
moving out of the parent ambient n and becoming its sibling, and "open n" 
causes dissolving the boundary of a child ambient n. In capability sequences, 
the left-most capability will be executed first. 

The constructors "0" , " I " , "." , "!" , and "z^" have standard meanings. Binders 
contain explicit type annotations (Sec. 14.2] below). The expression nlBI de- 
scribes the process B running inside ambient n. Capabilities can be communi- 
cated in messages. <A^i, . . . , Nk> is a process that sends a fc-tuple of messages, 
(ni -.LUi, . . . ,nk:u!k) -B is a process that receives a fc-tuple of messages, substi- 
tutes them for appropriate n^'s in B, and continues as this new process. Free 
and bound (basic) names are defined like in Meta+;. Processes that are a- 



Figure 7: Syntax and semantics of Tma. 
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::= Amb[K] | Cap[K] 
::= Shh | tJi (g) • • ■ (g) tjfe 
— AName — !>tin AMessageType 



Syntax of TmA types: 

id G AMessageType 
K G AExchangeType 
A £ AEnvironment 

Typing rules of TmA; 
A(n) = cj A h n : a; 
A h TV : Amb [k] ^ A h in iV : Cap M 
A h TV : Amb [k] ^ A h out TV : Cap M 
A h AT : Amb M => A h open : Cap M 



A h e : Cap [k] 

A h TV : Cap M & A h TV' : Cap [k] ^ 
A h Af.Af' : CapM 



. , A h TV : CapM & A h B : A h Af.B : «: 

'•''^ AhTV: AmbM & AI-B:K^Ah TV[B] : 

■'^ AI-Bo:«:&AhBi:K^AhBolBi:K 

A[7i 1-^ Amb [«:'] ] h B : K ^ A h (!/n : Amb [k'] )B : k 
yi: < i < k &i A \- Ni : ivi ^ A h <TVi, . . . , TVfc> : a;i (g) • • • (g) Wfc 
A[ni LJi, . . . , Wfc H^. h B : oji (g) • • • (g) LUk^ 
A h (rii . . . , TZfc :ajfc) .B : a;i (g) • • • (g) (^fe 

Figure 8: Syntax of Tma types and typing rules. 



convertible are identified. A substitution tr is a finite function from names to 
messages and its application to B is written Ba. Fig. [7] also describes struc- 
tural equivalence and semantics of Ma processes. The only thing the semantics 
does with type annotations is copy them around. We require all processes to be 
well-scoped w.r.t. conditions Sl-3 from Sec. 13.11 and the additional condition 
(S4) that the same message type is assigned to bound names with the same 
basic name. Ambients and capabilities where TV is not a single name, which the 
presentation allows for simplicity, are inert and meaningless. 

Example 4.1 In this example, packet ambient p delivers a synchronization 
message to destination ambient d by following instructions x. As we have not 
yet properly defined message types, we only suppose ujp = Amb[K] for some k. 

B = <in d> I {i^p:ojp){d [open p.O] I (x : a;x).p [x.o] ) — ^ 

(i^p:tjp)(d [open p.O] I p[in d.o]) — ^ (z/p : ajp)(d [open p.O I p[<>]]) d [<>] 

4.2 Types for Mobile Ambients (Tma) 

An arity mismatch error, like in "<a, b>.0 I (x).in x.O", can occur in polyadic 
Ma. Another communication error can be encountered when a sender sends 
a capability while a receiver expects a single name. For example "<in a>.0 I 
(x).out x.O" can rewrite to a meaningless "out (in a).0". Yet another error 
happens when a process is to execute a single name capability, like in "a.O". 
Processes which can never evolve to a state with any of the above errors are 
called communication safe. A typed Ma introduced by Cardelli and Gordon [3] , 
which we name Tma, verifies communication safety. 

Tma assigns an allowed communication topic to each ambient location and 
ensures that processes respect the topics. Fig. [8] describes Tma type syntax. 



12 



Exchange types, which describe communication topics, are assigned to processes 
and ambient locations. The type Shh indicates silence (no communication), 
wi® • • - (Sujk indicates communication of /c-tuples of messages whose i-th member 
has the message type cji. For k = we write 1 which allows only synchronization 
actions <> and (). Amb[K] is the type of an ambient where communication 
described by n is allowed. Cap[K] describes capabilities whose execution can 
unleash exchange k (by opening some ambient). Environments assign message 
types to free names (via basic names). Fig. |S] also describes the Tma typing 
rules. Types from conclusions not mentioned in the assumption can be arbitrary. 
For example, the type of N [B] can be arbitrary provided B is well-typed. It 
reflects the fact that the communication inside N does not directly interact with 
A'''s outside. Existence of some A and k such that A does not assign a Cap-type 
to any free name and A\- B : k holds implies that B is communication safe. 

Example 4.2 Take B from Ex. gj} A = {d ^ Amb [1] }, and ujp = Amb [1] , 
and Wx — Cap [1] . We can see that A h i? : Cap [1] but, for example, A\/ B : 1. 



4.3 Instantiation of Meta* to Ma 

When we omit type annotations, add "0" after output actions, and write capa- 
bility prefixes always in a right associative manner (like "in a. (out b.(in c.O))"), 
we see that the Ma syntax is included in the Meta*: syntax. The following set 
A instantiates Meta* to Ma. 

A = { active-C P in a [P] }, 

rewrite{a[in b.P I Q] I b [R] ^ b [a[P I Q] I R] }, 
rewrite{ a [b [out a.P I Q] I R] ^ a[R] I b[P I Q] }, 
rewrite-[ open a.P I a[R] ^ P I R> } U 
U^o{ rewrite{<Mi,...,Mfc>.P I (ai, . . . , afe).Q P I {ai := Mi, . . . , ifc := M^} Q > } 

The active rule lets rewriting be done inside ambients. It corresponds to the 
rule "i?o —^Bi^ nlBol n[i?i]". Each communication prefix length has 
its own rule as in the case of the 7r-calculus. A defines the calculus Cj, and the 
type system 5^. 

Communication safety of P can be checked on an ^-type as follows. Two 
edges with the same source labeled by (oi, . . . , a^) and <6i, . . . , bj> with k ^ j 
indicates an arity mismatch error (but only at active positions). Every label 
containing • (introduced by a substitution) indicates that a capability was sent 
instead of a name. Moreover, an edge labeled with a name a ^ ibn(P) at active 
position indicates an execution of a single name capability. A type of P not 
indicating any error proves P's safety. Checking safety this way is easy. 



Example 4-3. C^'s equivalent of B from Ex. 14. H is <{in d}»> 
P = <in d>.0 I i/p.(d[open p.O] I (x) .p [x.o.O] ). Its 

principal ^-type is displayed on the right. Its root 
is R and other node names are omitted. Checking 
the edge labels as described above easily proves P's 
safety. The edge labeled by x is not a communica- 
tion error because x is input-bound in P. 
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4.4 Embedding of Tma in Poly* 

Using the notation from Sec l2.4l we have that C is Ma, Sc is Tma, predicates 
tp are pairs (A, k), and S'c's relation l> B : is A h i? : k. Moreover TZ. \s A 
which was introduced with and Sj^ in Sec. 14.31 This section provides an 
embedding which shows how to, for a given B, A, and k, answer the question 
A h B : K using Sj,. We stress that it is primarily a theoretical embedding for 
proving greater expressiveness which is not intended for use in practice. 

An encoding {■) of Ma processes in Meta*, found in TR [HI Fig. 14], is again 
almost an identity except for the following. (1) Meaningless expressions allowed 
by Ma's syntax are translated using the special name •, e.g., "(in (out a)) = 
in •". (2) The encoding erases type annotations which is okay because Ma's 
rewriting rules only copy them around. The type embedding below recovers 
type information by different means. Prop. I^TT] holds in the given context. 

As discussed in Sec. 12. 4[ we can not translate (A, k) to a shape type with 
an equivalent meaning because h is preserved under renaming of bound basic 
names. Nevertheless this becomes possible when we specify the sets of allowed 
input- and i^-bound basic names and their types. These can be easily extracted 
from a given process B. An environment A^ (resp. A'^) from the top part of 
Fig. ini describes i/-bound (resp. input-bound) basic names of B. The definition 
reflects that i/-bound names in typable processes can only have Am b- types. For 
a given A, B, and k we construct the shape type (A U A^, A'^,k} such that 
A h B : K iff h (B) : (A U A^, A'g, 4. The construction needs to know which 
names are input-bound and thus they are separated from the other names. The 
well-scopedness rules Sl-4 ensure that there is no ambiguity in using only basic 
names to refer to typed names in a process. The type information I (Fig.[9l 2nd 
part) collects what is needed to construct a shape type. For / = (AU A^, A'g, k) 
we define A/, Aj , and ki such that A/ describes types of all names in A and 
B, and Aj describes types of B's input-bound names, and k/ is simply k. 

Example 4.4 A, B, and n from the previous examples (Ex. \4-l\ and Ex. \4-<^ 
give us I — {A U A^, A'^, Cap [1] ) and we have: 

AU As = {d 1^ Amb[l],p Amb[l]} A^" = {x Cap [1] } A/ = A U As U Aj 

The main idea of the construction of the shape type {/} from / is that (/) 
contains exactly one node for every exchange type of some ambient location, that 
is, one node for the top-level type k/, and one node for k' whenever Amb [k'] is in 
/. The top-level type corresponds to the shape type root. Each node correspond- 
ing to some K has self-loops which describe all capabilities and communication 
actions which a process of the type k can execute. When A/(d) = Amb [1] then 
every node would have a self-loop labeled by "in d" because in-capabilities can 
be executed by any process. On the other hand only the node corresponding to 
1 would allow "open d" because only processes of type 1 can legally execute it. 
Finally, following an edge labeled with "d [] " means entering d . Thus the edge 
has led to the node Xd that corresponds to 1. In the above example, the shape 
graph would contain edges labeled with "d [] " from any node to Xd • 
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Extraction of types of bound names: 

A'g (a) — uj iS B has a subprocess (. . . , a' : uj, . . .) .Bo 
A'^{a) = cj iff cj = Amb[K] &iB has a subprocess {va^ ■.uj)B(i 

Type information: 

I G Typelnfo = AEnvironment x AEnvironment x AExchangeType 

For a given I — (Ao, Ai, k) we write A/ for Ao U Ai, and Aj for Ai, and tii for k. 

Set of nodes of a shape graph (and correspondence functions) : 

typesj — {kj} U {k: Amb[fi:] G rng(A/)} nodeof/ — typeof7^ 

Let nodes/ be an arbitrary but fixed set of nodes such that there exist the bijection 
typeofj from nodes/ into typesj. 

Action types describing legal capabilities: 

namesof/(cj) — {a: A/(a) = uj} allowedin/(K) = moves/ U openSj(K) U comms/(K) 

moves/ — {in a, out a: 3k. a G namesof/(Amb [k] )} 

opens^(K) = {open a: a G namesof/(Amb [«;] )} U namesof/(Cap [k] ) 

msgSj(Amb [ac] ) — namesof/(Amb [k] ) 

msgSj(Cap [k] ) — namesof/(Cap [k] ) U {(moves/ U openSj(K))*} 
comms/(Shh) = comms/(aji ® • • • ® oj^) — {</ii, . . . , /ifc> : fii G msgs^(aji)}U 
{(ai, . . . ,ak) : A'" (a^) = oji & (i / j => 7^ a^)} 

Construction of shape predicates: 

{1} = {{I^, nodeof/(K/)) ^1} = {x x:"Sallowedin/(typeof/(x))&xGnodes/} U 

{x — ^ x'-'^Gn3rn6sof/(Amb[typeof/(x')])<fcXiX'Gnodes/ 

Figure 9: Construction of Poly* type embedding. 

The construction starts by building the node set of a shape predicate (Fig.|9l 
3rd part). All the exchange types of ambient locations are gathered in the set 
typesj. These types are put in bijective correspondence with the set nodes/. 

Example 4.5 Our example gives typesj — {Cap[l],l}. Let us take nodes/ = 
(R, 1} and define the bijections .such that nodeof/(Cap [1] ) = R and nodeof/(l) = 
1. 

The 4th part of Fig. [9] defines some auxiliary functions. The set namesof/(a;) 
contains all basic names declared with the type 00 by /. The set allowedin/(K) 
contains all Poly* action types which describe (translations of) all capabilities 
and action prefixes which are allowed to be legally executed by a process of 
the type k. The set allowedin/(K) consists of three parts: moves/, opensj(K), 
and comms/(K). The action types in moves/ describe all in/out capabilities 
constructible from ambient basic names in I. The set does not depend on k 
because in/out capabilities can be executed by any process. The set opensj(K) 
describe open-capabilities which can be executed by a process of the type k. 
The second part of opensj(K) describes names of the type CapCre] which might 
be instantiated to some executable capabilities. The set comms/(K) describes 
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communication actions which can be executed by a process of the type k. Its 
first part describes output- and the second input-actions. The auxihary set 
msgSj(a;) describes ah messages of the type w constructible from names in I. 

Example 4.6 Relevant sets for our example are: 

namesof/(Amb [1] ) = {d, p} opens^(l) = {open d, open p,x} 

namesof/(Cap[l]) = {x} opens^(Cap [1] ) =0 

comms/(l) = {<>, 0} moves/ = {in d,in p, out d,out p} 

com ms/ (Cap [1] ) = {<x>, <{in d, in p, out d, out p, open d, open p, x}*>, (x) } 

The bottom part of Fig. [H] constructs the shape graph {I\ and the shape 
predicate {/} from /. The first part of <|/|> describes self-loops of x which 
describe actions allowed to be executed by a process of typeof/(x). The second 
part of {I\ describe transitions among nodes. Any edge labeled by "a [] " always 
leads to the node which corresponds to the exchange type allowed inside a. 

Example 4.7 The resulting shape predicate (/) = (G, R) in our example is as 
follows. We merge edges with the same source and destination using "\ ". 

in diout dlin pi out pl<x>ICx)l \ d [] I p [] \ in d I out d I open d I 

<{x,in d,in p,out p, ( R 1 1 if^ P I oiJ* P I open p I 

out d,open d,open p}*> V y \ y x I <> I C) I p [] I d [] 

Correctness of the translation is expressed by Thm. 14.11 The assumptions 
ensure that no i/-bound name is mentioned by A or has a Cap- type assigned by 
an annotation. Here we just claim that (/) is always an A-type. 

Theorem 4.1 Let dom(A) n nbn(S) = and dom(A^) = nbn(B). Then it 
holds that Ah B : k if and only if h {B} : ((A U A^, A'g, k)) . 



4.5 Conclusions 

We embedded Tma's typing relation in Sj, (Sec. 14. 4p and showed how to recog- 
nize communication safety in S_a directly (Sec. 14. 3| ). The type {/} constructed 
in Sec. 14.41 can also be used to prove the safety of B. But then, it follows from 
the properties of principal types, that the safety of B can be recognized directly 
from its principal ,4-type. Thus any process proved safe by Tma can be proved 
safe by S^^ on its own. 

Some processes are recognized safe by Sj{ but not by Tma. For example, 
"(x:a;).x.O I <in a>" is not typable in Tma but it is trivially safe. Another 
examples show polymorphic abilities of shape types, for example, the Cyi process 

! (x, y, m) .x [in y.<m>.0] I <p,a,c>.0 I a [open p.O] I <q,b,in a>.0 I b[open q.O] 

can be proved safe by POLY>f: but it constitutes a challenge for Tma- like non- 
polymorphic type systems. We are not aware of other type systems for Ma and 
its successors that can handle this kind of polymorphism. 

The expressiveness of shape types (/} from Sec. 14.41 can be improved. In 
subsequent work 1], Cardelli, Ghelli, and Gordon define a type system which 
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can ensure that some ambients stay immobile or that their boundaries are never 
dissolved. This can be achieved easily by removing appropriate self loops of 
nodes. We can also assign nodes to (groups of) ambients instead of exchange 
types. This gives us similar possibilities as another Tma successor [5]. Moreover, 
we can use shape type polymorphism to express location-dependent properties 
of ambients, like that ambient a can be opened only inside ambient b. 



5 Conclusions and Future Work 

We discussed already the contributions (Sec. 11.11 12.51) . Conclusions for the 
embeddings were given separately fSec. 13.51 14. 5|) . Future work is as follows. For 
extensions, priorities are better handling of choice (e.g., because of its use in 
biological system modeling), and handling of rec which is in many calculi more 
expressive than replication and better describes recursive behavior. Moreover 
we would like to generalize actions so that calculi with structured messages, 
like the Spi calculus [5], can be handled. For applications, we would like to (1) 
relate shape types with other systems which also use graphs to represent types 
[lllITO], and (2) to study the relationship between shape types and session types 
i- 
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